Devices for carrying out remote payment transactions are well-known. These “payment terminals” include EFTPOS, credit card payment terminals, etc.
The most common function of payment terminals is to remotely access a persons account information and either carry out a transaction, such as crediting or debiting the account, or, particularly in the case of credit card payment terminals, to check the users account to ensure that there are sufficient funds to cover a transaction. Note that although credit card terminals do not necessarily remotely credit or debit the users account (the credit/debit transaction usually being carried out by a separate paper bill trail) and merely provide the information that the users account is sufficient to cover the transaction, such payment terminals still fall within the ambit of the present invention and the term “transaction” as used herein includes the operation of remotely checking the users account to “ok” a transaction.
A payment terminal may, for example, provide for the following basic operations:
(1) Input of information which is required to enable access to a customers account. The information is most often read from a magnetic stripe on a credit card or bank card or the like, or a smart card. In addition to reading details from a card a personal identification number (PIN) or the like code may also be required.
(2) Obtain access to the customers account. This is usually done by remote communication with a processing device holding the person's account data, usually on bank premises and remote from the payment terminal. Usually, information on the customers account input to the payment terminal will need to be transmitted for verification and to enable access to the account. Also a money amount will usually need to be input to the payment terminal and transmitted over the communications line. At least some and perhaps all of the transmitted data may be encrypted for security purposes and the payment terminal is therefore, in such a case, required to have means (3) providing encryption.
(4) The payment terminal may need to be able to receive communications over the remote line from the processor accessing the customers account, ie. to provide an “answer” to the payment device regarding the user transaction. The answer may include information that an account debit/credit has taken place (eg. EFTPOS) or merely an approval that the customer has enough money in his account to enable a transaction (some credit card payment terminals). Again, this transmitted information may be encrypted and, if so, will require translation (5) in the payment terminal.
(6) To provide an indication that the transaction request is approved or that a transaction has occurred, by display or printer, for example. Displays may also be required to prompt an operator or customer to input information, e.g., input your PIN “Input Amount”.
There are many different brands of payment terminal, utilising many different software and hardware arrangements. This gives rise to a number of problems.
Any account acquirer (eg. bank) will generally have their own operating requirements as to how remote payment transactions will be handled. The account acquirer may purchase a series of payment terminals which have been configured by a manufacturer to the acquirer's requirements. These payment terminals will then be licensed or rented or more often supplied at no charge to merchants (e.g., retail stores, garages, restaurants). Multiple account acquirers may require access to their customers accounts via a single payment terminal. That is, one particular merchant may operate payment terminals which provide access to customers accounts at other account acquirers (e.g., other banks). Because of different requirements of different acquirers for handling of remote payment transactions, the payment terminal must be arranged to operate to satisfy the different requirements.
The terminal owner (often a principle acquirer) will have the terminal appropriately arranged and programmed by the terminal manufacturer to satisfy the requirements of all account acquirers utilising the terminal. Payment terminals may need to contain several programs and select the appropriate program depending on the card to be processed or on an operator selection.
It is often the case that the terminal owner may need to have the operation of the payment device amended to, for example, enable it to operate for an additional account acquirer, or to satisfy changed requirements for a particular account acquirer. Because of the different hardware/software architectures available, any operational alterations generally the require the input of the terminal supplier or manufacturer. The supplier/manufacturer will be required to reprogram the terminal or amend the hardware in order to carry out the alterations and they will usually be the only person who has the appropriate knowledge. The terminal owner is thus tied to the particular supplier/manufacturer of the particular brand of payment terminal.
It is often the case that, the terminal owner may over time obtain different brands from different manufacturers and for operational alterations may need to return the particular brand to each separate manufacturer. Over time, manufacturers may go out of business, in which case the payment terminals made by that particular manufacturer may be unsupported and any alteration may be difficult to achieve, or at least will require the input of a skilled person having detailed knowledge of the programming and/or hardware of the redundant manufacturer's devices.
Being tied to a particular manufacturer for a particular brand therefore causes cost, time and trouble when any operational alterations are required. There is therefore a reluctance to carry out operational alterations, which sometimes means that requirements of various account acquirers are not fully satisfied. When an operational alteration does have to be carried out, it is costly. If a manufacturer goes out of business, the terminal owner may be left with nobody to alter the operation of his payment terminals, or indeed maintain the payment terminals. The present system is costly and inflexible.
A payment terminal device usually includes a microprocessor and a number of peripheral units (e.g., card reader, display, printer, communications interface, _etc) controlled by the processor. A payment terminal device usually comprises hardware, an operating system or a BIOS and is ready to accept an application for that arrangement. Or the device may be supplied with an interpreter to accept the applications.
To alter the operation of payment terminals, a new application must be created. This can be time consuming, costly and as the programming will be different for different types of devices, which may have different hardware arrangements as well, and must be carried out separately for each different type of device (i.e., different reprogramming operations must be carried out for different devices even where the same operational alterations may be required).
The programming alterations are not “portable” between different types of devices.
The most time critical aspects of operation of a remote payment terminal involve the building up and breaking down of “messages” and the formulation and operation of communications. By “messages” is meant, for example, information data which is required to be input to the device or communicated or displayed in order to enable carrying out of a remote payment transaction, and includes information to be communicated to the bank, e.g., customers card number, customers PIN, amount of transaction, etc; displayed information such as “Please Input Amount”; information to be read from a customers magnetic stripe card or smart card and manipulated by the device e.g., card number, expiry date, etc. The operation of payment terminals is greatly concerned with the collection, rearrangement and communication of this message data to enable a remote payment transaction.
In conventional devices, each time a message is constructed or deconstructed, the operation of the machine will be handled by the application program. To change operation of the machine, the application must be changed. This is laborious, and gives rise to problems, as discussed above.
The technique of creating a _virtual processor_ (or in this case microprocessor) is well known and referred to as an interpreter. This allows programs to operate independent of processor. With the newer technique of also creating virtual peripherals then the whole is referred to as a “virtual machine”.
A_virtual machine_ is computer programmed to emulate a hypothetical computer. Different incompatible computers may be programmed to emulate the same hypothetical computer. Any computer programmed to emulate the hypothetical computer will thus be capable of executing programs for the virtual computer. This creates a complete portable environment for program operations.
A problem with virtual machines is emulation is slower than normal program execution. For some applications this performance penalty is a significant problem.
The above problems and disadvantages which have been discussed specifically in relation to devices configured to process payment transactions also would apply to devices configured to prepare and process any information to be sent or received via a network, not restricted to payment transaction information.